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1  INTRODUCTION 


1.1  Purpose 

The  purpose  of  the  Zen  Regard  Experiment  was  to  develop  and  demonstrate  the  key 
technologies  necessary  to  support  worldwide  command  and  control/  surveillance/ 
targeting/  attack  and  bomb  damage  assessment  for  fut\ire  warfighting  in  the 
Distributed  Interactive  Simulation  (DIS)  Network  arena.  The  Zen  Regard 
Experiment  was  conducted  over  approximately  13  locations  throu^out  the  United 
States.  The  Mounted  Warfare  Testbed  (MWTB)  and  the  Aviation  Testbed  (AVTB) 
were  the  two  locations  controlled  by  the  Loral  ADST  Program  Office. 

1.2  Background 

War  Breaker  develops  and  demonstrates  capabilities  enabling  and  integrated/  end- 
to-end  system  that  detects/  identifies/  targets,  and  neutralizes  time-critical  targets. 
The  War  Breaker  program  focuses  on  key  on-going  ARP  A  technology 
developments,  augmented  with  new  high  leverage  Service  initiatives  and  closely 
coupled  with  the  Precision  Stike,  Global  Surveillance,  and  Communication  Science 
and  Technology  thrusts.  Although  War  Breaker  is  aimed  at  killing  theater  ballistic 
missiles,  the  enabling  technologies  are  directly  applicable  to  other  time-critical 
targets.  ARPA  is  striving  for  a  fully  integrated  warfighting  system,  with  system 
engineering  supported  by  the  Distributed  Defense  Simulation  .wargaming 
environment. 

The  Distributed  Defense  Simulation  wargaming  environment  combines 
simulations  and  simulators  capabilities  from  all  branches  of  the  Armed  Forces 
offering  the  capability  of  visualizing  and  communicating  system  performance, 
requirements,  and  man-in-the-loop  interactions  in  an  operational  context. 

13  FCXIUS 

The  focus  of  this  experiment  is  on  time  critical  mobile  and  fixed  targets  such  as 
tactical  ballistic  missile  launchers,  command  and  control  nodes,  integrated  air 
defense  systems,  etc.  The  following  items  are  some  of  the  major  objectives  of  the 
Zen  Regard  Experiment. 

•  Analyze  DIS  Simulations  capability  to  support  multi-service  exercises 

•  Determine  effectiveness  of  DIS  for  evaluating  the  DTLOMS  domain 

•  Establish  DIS  network  for  future  Modeling  and  Simulation  efforts  of  current 
capabilities 

•  Integrate  new  and  emerging  warfighting  concepts 
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2  LESSONS  LEARNED 

2.1  MOUNTED  Warfare  testbed 

This  section  was  written  directly  by  the  technical  participants  at  the  MWTB,  Italic 
comments  are  additions  from  the  program  manager. 

A)  ISSUE.  We  need  to  get  into  the  exercise  earlier  than  we  did.  All  the  good  testing 
times  were  missed.  This  was  mainly  due  to  delays  in  getting  the  red  gateway  and 
NES  equipment  devices  installed  on  time. 

SOLUTION.  Should  not  be  a  problems  now  that  the  initial  setup  is  complete.  One 
area  of  concern  is  that  since  we  do  not  have  a  secure  area  in  die  building  at  all  times, 
we  cannot  run  the  gateway  to  keep  up  with  software  updates  for  the  gateway  and  the 
NES’s,  These  will  have  to  be  dealt  with  if  and  when  we  run  the  exercise  again. 
Impacts  the  set-up  time  for  every  experiment.  The  solutions  to  this  is  to  secure  the 
MWTB  as  a  classified  SECRET  facility. 

B)  ISSUE.  We  needed  to  be  more  involved  in  the  planning  of  the  exercise  and 
attend  more  meeting  in  order  to  imderstand  the  big  picture  a  little  better. 

SOLUTION.  More  trips  to  attend  IPR’s,  etc.  Future  proposal  will  include  some 
travel  dollars  for  the  technical  participant  lead  for  each  experiment. 

C)  ISSUE.  The  assistance  from  NRAD  and  Warbreaker  was  pretty  good  once  we 
found  the  correct  people  to  talk  to.  There  was  still  a  language  barrier  concerning 
what  they  were  seeing  and  identifying  as  our  vehicles,  etc.  It  was  very  difficult  if  not 
impiossible  to  say  who  or  what  was  causing  the  problem.  There  was  a  continuous 
problem  in  figuring-out  who  (what  site)  was  causing  the  problem. 

SOLUTION.  A  better  defined  way  for  each  site  to  identify  vehicles  so  that  we  could 
easily  communicate  this  info  between  each  other.  Some  of  this  would  also  have 
been  eliminated  if  we  had  been  in  the  exercise  from  the  beginning.  Longer  testing 
period  is  needed  with  a  more  controlled  test  procedure. 

D)  ISSUE.  We  need  more  control  at  our  site  to  eliminate  the  amoimt  of  data 
coming  in  to  us.  The  simulations  at  the  MWTB  could  not  handle  the  1300+  entities 
that  they  were  seeing  on  the  network. 

SOLUTION.  Control  of  site  id's,  exercise  id's  and  vehicle  id's  via  a  filtering  device 
such  as  the  protocol  translator. 

E)  ISSUE.  Our  simulators  and  SAP  need  to  be  upgraded  to  be  able  to  view  larger 
numbers  of  vehicles  easier. 

SOLUTION.  Software  and  CIG  upgrades.  This  entails  the  purchase  new  hard 
drives  and  memory. 


Page  2 


Advwwad  OMifeuiad  StowMlon 


F)  ISSUE.  We  need  a  software  package  to  help  identify  vehicles/  etc.  in  several 
different  forms.  There  are  so  many  different  version  and  types  of  vehicles  that 
have  been  added  to  the  various  sites,  other  sites  have  not  been  able  to  keep  track. 

SOLUTION.  Software  development.  Update  Ft.  Knox  vehicle  libraries. 

G)  ISSUE.  We  need  to  have  a  secure  area  in  the  building  to  eliminate  the  need  for 
24  hour  guards  and  make  it  easier  on  us  to  establish  the  area  for  testing. 

SOLUTION.  Develop  secure  area.  Same  as  Issue  A. 

2J.  Aviation  Testbed 

This  section  was  written  directly  by  the  technical  participants  at  the  AVTB. 

The  Aviation  Test  Bed  at  Ft.  Rucker,  Alabama  participated  in  the  Zen  Regard  test 
and  demonstration  from  1-10  Nov.  93.  From  a  networking  and  interoperability 
standpoint,  the  exercise  did  not  achieve  its  objectives.  The  AVTB  did  not  effectively 
or  meaningfully  participate  in  the  exercise  due  to  many  technological  limitations. 
Below  is  an  explanation  of  those  limitations,  their  effect  on  AVTB  conduct  of  the 
exercise  and  recommended  solutions  for  each.  The  AVTB  staff  will  take 
action/ coordinate  to  correct  these  deficiencies. 

A)  ISSUE.  Floating  or  Subterranean  targets. 

DISCUSSION.  When  seen  at  all,  vehicles  generated  for  the  Zen  Regard  exercise 
were  shown  either  as  150  meters  below  the  terrain  surface  or  floating  50  meters 
above  the  ground.  Entities  for  the  exercise  were  generated  by  the  Theater  Air 
Command  and  Control  Simulation  Facility  (TACCSF)  and  routed  through  NRaD 
for  SIMNET  conversion  for  the  AVTB.  Thus  there  were  two  points  of  failure, 
neither  of  which  were  under  the  control  of  the  AVTB.  This  problem  was  either 
cause  by  TACCSFs  use  of  an  older  release  of  the  terrain  data  base  or  the  poor 
adjustment  of  the  protocol  translator,  or  a  combination  of  both. 

RECOMMENDATION.  All  participants  must  use  the  most  cxirrent  common  data 
bases.  Use  the  on  site  DIS  2.03  translator  in  the  AVTB  facility  to  allow  local 
adjustments  of  target  height  and  orientation. 

B)  ISSUE.  Flashing  Targets. 

DISCUSSION.  Throughout  the  exercise  threat  vehicles  would  appear  and  disappear. 
This  is  thought  to  be  caused  by  the  slow  update  rate  forced  on  die  many  entities  by 
the  constrictions  produced  by  Network  Encryption  Systems  (NES)  and  protocol 
translators.  Besides  the  poor  visual  representation  of  vehicles,  the  result  of  this 
flashing  was  an  inability  to  effectively  engage  targets  with  Hellfire  missiles  as  the 
target  would  frequently  disappear  prior  to  missile  impact.  The  target  would  reappear 
seconds  later,  too  late  for  an  effective  engagement. 
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RECOMMENDATION.  Two  options.  One  is  to  decrease  the  number  of  threat 
clutter  vehicles,  thereby  increasing  available  bandwidth  and  allowing  more  frequent 
entity  updates.  The  other  is  to  generate  all  entities  for  targeting  by  one  machine  and 
allow  the  machine  to  update  as  frequently  as  required  (5  seconds  for  SIMNET),  and 
give  low  update  priority  to  separately  generated  dutter  so  they  drop  out  first. 

C)  ISSUE.  Sensor  range  on  Apache  simulators  initially  limited  to  3.5  kilometers. 

DISCUSSION.  The  expanded  Saudi  Arabia  -  Kuwait  -  Iraq  (SAKI)  terrain  data  base  is 
so  large  it  requires  additional  memory  to  generate  the  out  the  window  (OTW)  and 
FLIR/DTV  view.  All  available  memory  was  used  to  produce  the  OTW  scene,  which 
left  the  sensor  view  restricted  to  3.5  km.  This  is  unsuitable  for  attack  helicopter 
operations.  A  redistribution  of  installed  memory  solved  the  sensor  limit  problem. 
However,  the  solution  resulted  in  the  "downing"  of  the  other  6  CIG’s  on  site  for  the 
duration  of  the  exercise. 

RECOMMENDATION.  STRICOM  authorize  AVTB  to  purchase  required  additional 
memory  for  all  12  CIGs  on  site. 

D)  ISSUE.  Inaccurate  target  icons. 

DISCUSSION.  During  the  exercise  SCUD  transporter  erector  launchers  would 
appear  to  air  crews  as  5  ton  trucks  and  SA-13’s  as  M-113's.  This  is  because  the  AVTB 
does  not  have  the  required  memory  and  texture  PROM  chips  to  process  the  large 
vehicle  description  files.  The  electronic  Dynamics  Effects  Database  file  (DED) 
contains  the  description  of  each  vehicle's  appearance  and  characteristics.  This  file  is 
centrally  built  and  distributed  to  participants  through  the  War  Breaker  systems 
engineering  team.  For  each  exercise,  a  DED  file  is  built  and  distributed.  A  central 
library  of  DED  files  that  would  allow  local  construction  of  locally  required  vehicles 
files  would  provide  flexibility  to  each  site  according  to  its  capabilities. 

RECOMMENDATION:  Ensure  AVTB  has  the  most  current  DED  files  on  hand  and 
loaded  prior  to  the  exercise.  Purchase  additional  memory  and  texture  PROMs  as 
required  to  process  and  display  the  icons  vital  to  proper  exercise  execution. 
STRICOM  sponsor  the  development  of  a  master  DED  library  to  facilitate  the  build  of 
flexible  DED  files  for  specific  exercises. 

E)  ISSUE.  Invisible  solid  "walls  in  space"  on  the  terrain  data  base. 

DISCUSSION.  During  the  execution  of  the  mission,  aircraft  would  randomly  and 
without  warning  crash  in  mid-air.  The  aircraft  would  be  reset  to  rejoin  the  flight  at 
the  next  ACP.  This  was  caused  by  abnormalities  in  the  terrain  data  base.  The  data 
base  is  built  by  the  Topographic  Engineering  Center  in  Ft.  Belvoir. 

RECOMMENDATION.  TEC  recompile  the  SAKI  terrain  data  base  and  provide  to 
AVTB  as  soon  as  possible  for  testing. 

F)  ISSUE.  Lack  of  management,  command  and  control  (MCC)  system  control  of  the 
simulation. 
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DISCUSSION.  The  MCC  is  a  system  which  provides  fimctiox\s  such  as  initialization, 
rearm,  refuel,  close  air  support,  fire  support  and  assignment  of  aircraft  ID  numbers. 
This  deficiency  restricted  local  control  of  JSEAD,  FARP  use,  and  greatly  complicated 
the  commander's  ability  to  rapidly  identify  aircraft.  This  was  caused  by  the  lack  of  a 
terrain  data  base  specifically  compiled  for  the  Masscomp  computer  which  controls 
MCC  fimctions. 

RECOMMENDATION.  TEC  create  the  expanded  SAKI  database  for  use  on  the 
Masscomp  computer. 

G)  ISSUE.  Limited  mimitions  available  for  use  by  AH-64. 

DISCUSSION.  Air  crews  could  not  use  Hydra  rockets  loaded  with  MPSM  warheads. 
This  limitation  is  due  to  the  fragility  of  the  War  Breaker  network.  The  multiple 
explosions  created  by  submunition  impact  saturated  the  network  and  were  not 
handled  by  the  very  busy  protocol  converter  at  NRaD.  Each  trigger  pull  causes  18 
explosions,  and  when  an  aircraft  salvos  or  multiple  aircraft  fire,  saturation  happens 
quickly,  this  is  not  a  problem  that  can  be  fixed  near  term,  as  it  is  a  basic  architecture 
problem  with  dissimilar  simulator  networking. 

RECOMMENDATION.  Limit  weapon  load  to  16  Hellfire  or  8  Hellfire  and  10  potmd 
warheads. 

H)  ISSUE.  The  target  would  show  no  effect  and  reappear  when  hit  by  hellfire 
missiles. 

DISCUSSION.  The  firing  Apache  would  see  missile  impact  but  no  effect.  This  is  a 
basic  problem  in  networking  dissimilar  simulations.  Each  target  is  responsible  for 
registering  impact  and  damage,  then  broadcasting  results.  If  the  target  does  not 
recognize  the  type  round  or  it's  capabilities,  no  effect  will  be  broadcast  or  seen  by 
firing  unit.  The  human  operator  can  manually  destroy  the  target  if  he  views  the 
engagement. 

RECOMMENDATION.  War  Breaker  system  engineering  team  coordinate  and 
schedule  more  robust  testing  in  order  to  confirm  and  adjust  target  effects. 

I)  ISSUE.  Filtering  of  targets  at  NRaD. 

DISCUSSION.  The  great  number  of  entities  generated  as  both  clutter  and  targets 
overwhelmed  the  Semi  Automated  Force  system  operating  at  Ft.  Knox.  The  Knox 
system  would  shut  down  upon  entering  the  populated  network  because  they  were 
producing  a  large  number  of  entities  themselves.  To  alleviate  this  problem  I  agreed 
that  NRaD  should  filter  out  the  clutter  so  that  only  the  target  entities  were  broadcast 
to  AVTB  and  Knox.  However  all  entities  were  filtered  the  following  day  with  the 
results  that  AVTB  saw  no  other  participants.  The  AVTB  was  forced  to  generate 
targets,  thereby  negating  the  effectiveness  of  distributed  simulation.  The  filtering  of 
targets  to  satisfy  this  one  deficient  node  effectively  nullified  all  participation  by  the 
AVTB,  with  the  resultant  waste  of  time,  money  and  manpower. 
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RECOMMENDATION.  Four  solutions  possible.  First  is  to  decrease  the  number  of 
entities  generated  by  Ft.  Knox,  thereby  increasing  the  number  of  externally  generated 
entities  both  they  and  the  AVTB  can  see.  Second  is  to  filter  out  the  clutter  entities, 
so  that  only  target  vehicles  are  broadcast  to  Knox  and  the  AVTB.  Third  is  to  alter 
network  architecture  so  that  operations  at  the  AVTB  are  independent  of  those  at  Ft. 
Knox.  Last  would  be  to  eliminate  Ft.  Knox  from  further  War  Breaker  participation, 
as  the  armored  force  has  no  role  in  the  prosecution  of  time  critical  mobile  targets, 
and  their  participation  limits  the  effectiveness  of  the  AVTB,  representing  a  viable 
strike  force. 

J)  ISSUE.  Insufficient  testing  of  War  Breaker  network  architecttire. 

DISCUSSION.  The  AVTB  was  not  part  of  any  large  scale  network  loading  tests  to 
identify  load  based  problems.  Numerous  problems  first  discovered  on  1  November 
should  have  been  identified  and  resolved  prior  to  STARTEX.  The  network  test 
schedule  was  insufficie'!;  and  assumed  schedule  flexibility  for  the  AVTB  that  does 
not  exist.  The  AVTB  built  its  schedule  around  the  identified  network  periods, 
precluding  last  minute  connectivity  test  requests. 

RECOMMENDATION.  War  Breaker  planning  group  must  plan  for  and  adhere  to  a 
robust  testing  schedule  that  shakes  out  potential  problems  and  verifies  solutions 
before  the  beginning  of  the  next  exercise. 

K)  ISSUE.  Lack  of  security  classification  gmde,  DD  254,  Zen  Regard. 

DISCUSSION.  Although  deemed  a  "Secret/NOFORN"  exercise,  the  agency  at  War 
Breaker  responsible  for  seoirity  did  not  and  has  not  published  the  required  DD  254. 
This  document  outlines  for  the  contractor  what  information  is  classified  and  how  to 
protect  it.  Throughout  the  exercise  the  AVTB  contractor  was  forced  to  treat 
everything  as  Secret  information.  This  was  the  only  way  to  ensure  no  compromise 
was  possible.  This  both  complicated  daily  operations  and  put  the  AVTB  at  risk. 
Loral  agreed  to  process,  store  and  issue  presumed  classified  data,  although  such 
actions  without  guidance  is  contrary  to  the  industrial  security  standards. 

RECOMMENDATION.  War  Breaker  security  group  approve  and  publish  DD  254 
immediately. 
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APPENDIX  A 


BDM  LESSONS  LEARNED  REPORT 


BDM  INTERNATIONAL.  INC. 


WarBreaker  Zen  Regard  Lessons  Learned 


The  following  Issue  and  discussion  Items  pertain  to  the  portion  of  the 
WarBreaker  Zen  Regard  exercise  recently  conducted  In  the  Mounted  Warfare 
Test  Bed  (MWTB)  and  at  the  Aviation  Test  Bed  (AVTB).  These  lessons 
learned  are  intended  to  provide  insight  Into  difficulties  encountered 
during  the  project  and  should  be  evaluated  prior  to  the  next  iteration 
of  exercises  Involving  multi -site  operations  and  exercises  involving 
large  data  bases.  Contributors  to  this  list  for  MWTB  were  Mr.  Rick 
Lozicki  of  BOM  Federal,  Inc.,  and  Mr.  Jimmy  Adams  of  LTTS;  input  for 
AVTB  observations  was  obtained  from  Mr.  Bill  Parson  of  BDM  Federal,  Inc. 

1.  Site  Equipment  Problems. 

1.1.  Issue:  There  was  a  lack  of  equipment  available  for  the  MWTB 
Exercise  Control  Officer,  thereby  limiting  his  effectiveness. 

1.1.1  Discussion:  Only  two  SGI  platforms  were  in  the 
operations  cell  running  SAFOR.  The  Exercise  Control  Officer  was 
required  to  view  the  battlefield  by  looking  at  -  SAFOR  screen  while  also 
trying  to  monitor  the  Stealth  view. 

1.1.2.  Discussion:  The  need  to  use  the  SAFOR  systems  to 
position  and  attach  the  Stealth  often  precluded  the  Exercise  Control 
Officer  from  processing  information  from  units.  The  Exercise  Control 
Officer  therefore  had  to  wait  until  he  could  gain  access  to  a  SAFOR 
terminal  in  order  to  deal  with  incoming  information  from  the  vehicle 
commanders. 


1.2  Issue:  The  MWTB  SAFOR  systems  often  crashed  during  the 
conduct  of  the  exercises. 

1.2.1  Discussion:  The  current  SAFOR  systems  cannot  handle 
the  amount  of  information  being  sent  over  the  net  during  the  exercises. 
The  MWTB  needs  the  ability  to  filter  out  sites  from  the  network  which 
are  not  necessary  for  the  accomplishment  of  the  mission.  The  protocol 
translator  and  other  associated  equipment  should  be  used  before  the 
start  of  an  exercise  to  check  out  all  system  elements. 

1.3  Issue:  The  Stealth  vehicle  and  simulators  ' were  unable  to 
see  vehicles  that  were  actually  within  200  meters  of  them. 

1.3.1  Discussion:  The  CIGs  running  the  Stealth  vehicle  and 
simulators  could  not  process  the  amount  of  data  gathered  during  the 
exercise.  Upgrades  or  new  versions  of  the  CIGs  are  needed  to  allow  a 
greater  data  collection  capacity. 

1.4  Issue:  Vehicles  generated  by  other  sites  appeared  on  the 
SGI  SAFOR  screens  but  could  not  be  seen  by  the  MWTB  Stealth  vehicle. 

1.4.1  Discussion:  Many  of  the  vehicles  (both  ground  and 
air  elements)  appeared  on  the  SAFOR  screens,  but  when  attached  to,  could 
not  be  found.  The  SAFOR  could  describe  them  as  friendly  or  enemy  but 
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could  not  identify  their  model  or  type.  A  software  upgrade  is  needed  to 
allow  any  entity  generated  by  another  site  to  be  viewed  and  identified. 

1.5  Issue;  Some  of  the  newly  developed  software  for  MWTB  was 
inoperable. 

1.5.1  Discussion:  For  this  exercise,  a  new  terrain 
database  was  developed  for  the  Management  Command  and  Control  (MCC) 
system  to  place  the  two  M2‘s  and  two  Ml's  in  their  locations.  The  same 
MCC  is  also  used  to  place  artillery  and  engineer  elements  for  producing 
the  requested  artillery  fires  and  minefields.  We  were  able  to  place 
simulators  only;  the  system  would  not  allow  the  placement  of  artillery 
or  engineer  assets  into  the  exercise. 

1.6  Issue:  Placing  MWTB  simulators  via  the  SIMNET  Control 

Console  (SCO  was  difficult  if  the  MWTB  was  on  the  network  at  the  time. 

1.6.1  Discussion:  A  simulator's  parameters  entered  into 
the  see  (starting  grid  location,  ammo  load,  etc.)  became  altered  when 
the  simulator  was  subsequently  placed.  Simulators  should  be  placed 
before  any  network  traffic  begins  or  with  the  Gateway  disconnected. 
Once  the  vehicles  are  set.  the  Gateway  should  then  be  connected. 

1.7  Issue.  AVTB  Memory  Capacity. 

1.7.1  Discussion.  The  expanded  SAKI  terrain  data  base  is 
large  and  requires  significant  memory  to  generate  the  out-the-window 
(OTW)  and  Forward  Looking  Infrared  Radar/  Day  Television  View  (FLIR/DTV) 
views  required  for  AVTB  aerial  vehicles.  Since  all  available  memory  was 
allocated  to  OTW  mapping,  the  sensor  views  for  the  AH-64  were  limited  to 
3.5  km,  which  is  unsuitable  for  Attack  Helicopter  operations.  A 
temporary  fix  to  installed  memory  was  instituted  locally  by  downing  6 
other  on-site  CIGS. 

2.  Inter-site  Issues 

2.1  Issue;  Coordination  of  vehicle  visibility  across  sites. 

2.1.1  Discussion;  Neither  MWTB  nor  AVTB  could  see  the 
elements  from  the  other  site.  Since  no  one  knew  who  was  supposed  to  see 
who  on  the  network,  it  was  hard  to  determine  whether  Or  not  everything 
was  working. 


2.1.2  Discussion;  MWTB  received  word  from  WarBreaker 
Headquarters  that  some  of  the  M3s  that  put  out  looked  like  "blobs"  to 
them.  The  also  reported  that  one  of  the  SAFOR  Mis  appeared  similarly; 
no  explanation  for  this  anomaly  was  determined. 

2.1.3  Discussion:  WarBreaker  Headquarters  identified 
vehicles  differently  than  did  MWTB.  They  used  Latitude  and  Longitude  to 
define  locations  rather  than  X,  Y  coordinates  or  UTM  grids  used  in 
SIMNET.  A  common  language  for  the  WarBreaker  network  needs  to  be 
established. 
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2.1.4  Discussion:  Many  of  the  other  sites  had  different  or 
larger  terrain  databases  and  their  vehicles  appeared  outside  the 
database  used  by  the  MWTB.  Every  effort  needs  to  be  tnade  to  have 
everyone  on  the  same  playing  field;  otherwise,  deviations  should  be 
explained  to  all  participants. 

2.2  Issue.  Dissimilar  systems  problems. 

2.2.1  Discussion.  Update  rates  by  controlling  DIS  systems 
caused  computer  generated  systems  at  AVTB  to  blink  in  and  out  during 
crucial  times.  This  resulted  in  the  AH-64  Crew's  inability  to  maintain 
Hellfire  lock  on  the  target  all  the  way  to  missile  impact. 

2.2.2  DED  files,  reflecting  appropriate' 'exercise  models 
need  to  be  standardized  and  disseminated  to  using  sites.  Non-standard 
DED  files  result  in  "Beach  Ball"  clutter  and  often  causes  site  systems 
to  malfunction/crash. 

3.  Exercise  Operations  Problems. 

3.1  Issue;  Scheduling/Admini strati ve  Issues. 

3.1.1  Discussion:  Equipment  scheduled  for  use  during  the 
exercise  should  be  identified  as  soon  as  possible  and  installed  prior  to 
the  beginning  of  scheduled  exercise  testing  times.  Some  of  the  red 
long-haul  equipment  was  still  being  installed  when  system  tests  were 
initiated.  This  put  both  MWTB  and  AVTB  behind  and  did  not  allow  either 
to  catch  up.  Early  installation  of  the  protocol  translator  and 
associated  equipment  would  allow  time  to  check  things  out  prior  to  the 
start  of  an  exercise.  More  involvement  of  the  site  staffs  during  the 
planning  stages  in  order  to  better  understand  the  requirements  and  total 
concepts  would  also  help. 

3.3  Issue;  Scheduling  of  soldiers. 

3.3.1  Discussion;  A  better  job  needs  to  be  done  of  letting 
troops  know  when  changes  to  the  exercise  schedule  occur.  Troops  did  not 
always  get  the  word  when  practice  runs  were  canceled.  At  other  times, 
network  problems  resulted  in  soldiers  being  at  the  MWTB  when  the  system 
was  down.  The  responsibility  for  troop  notification  needs  to  be  clearly 
established  before  exercises,  so  as  to  avoid  embarrassment  to  the 
Government  or  to  the  contractor  team. 

3.2  Issue.  Exercise  Control. 

2.1.1  Discussion.  The  flow  of  Communications  from  higher 
echelons  to  respective  player  cells  was  inadequate.  Threat  templating 
and  other  IPB  requirements  were  never  disseminated  from  higher  to  lower 
echelons.  As  a  result,  the  utilization  of  Close  Air  Support  (CAS)  and 
Suppression  of  Enemy  Air  Defenses  (SEAD)  was  not  introduced  or 
controlled  throughout  the  programmed  mission. 
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3.3  Issue.  Inadequate  scenario  preparation. 

2.3.1  Discussion.  To  ensure  continuity  that  the  AH-64's 
were  able  to  achieve  realistic  targeting  in  the  designated  engagement 
areas,  appropriate  targets  had  to  be  self -generated  by  AVTB.  This  was 
performed  with  NRaO's  authorization. 

3.4  Issue:  Securing  the  MWTB 

3.3.1  Discussion:  A  secure  area  needs  to  be  established  in 
the  MWTB  to  eliminate  the  need  for  24-hour  guards  and  all  other 
requirements  necessary  to  establish  and  conduct  a  classified  exercise. 

4.  Pre-Exercise  Testing 

4.1  Issue.  Disparities  in  terrain  data  bases.  Initial  and  on¬ 
going  connectivity  testing  was  inadequate  considering  the  magnitude  of 
the  effort.  Examples  of  the  resulting  difficulties  include  the 
following: 


4.1.1.  Discussion.  Virtually  all  testing  between  NRaD  and 
AVTB  was  conducted  on  the  NWIRAQ  Terrain  data  base.  Although  several 
atten^ts  were  made  to  determine  which  terrain  data  base  would  be 
utilized  for  the  demonstration,  this  was  not  disclosed  until  late  in  the 
process.  Compounding  the  problem  was  the  fact  that,  while  all  of  the 
connectivity  testing  was  done  using  NWIRAQ,  the  actual  experiment/demo 
was  conducted  entirely  on  the  SAKI  terrain  data  base.  Many  of  the 
problems  associated  with  the  SAKI  terrain  data  base,  such  as  "Walls  in 
Space",  Terrain  clamping,  and  unaligned  terrain  intervals,  to  name  a 
few,  could  have  been  identified,  and  perhaps  corrected  prior  to  exercise 
execution,-  had  that  data  base  been  used  during  the  testing. 

4.1.2.  Discussion.  Designated  systems  proposed  by  the  Zen 
Regard  Playbook  should  have  been  employed  and  fully  tested  for 
compatibility  during  the  connectivity  phase.  AVTB  was  only  permitted  to 
test  a  single  AH-64  against  a  few  selected  systems  in  lieu  of  the  full 
playbook  contingent. 


4.1.3.  Discussion.  Problems  associated  with  TACCSF 
generated  vehicles  appearing  either  150  meters  below  the  terrain,  or 
floating  50  meters  above  the  ground  adversely  affected  program 
objectives.  Although  efforts  were  initiated  to  rectify  the  problem  with 
TACCSF,  their  vehicles  never  achieved  the  proper  terrain  clamping 
profile.  When  floating  TACCSF  systems  were  engaged  by  Hell  fire 
missiles,  visual  destruction  could  not  be  ascertained  as  a  result  of 
this  problem.  It  should  be  noted  that  similar  problems  between  MWTB  and 
AVTB  were  encountered  in  the  recent  NLOS-CA  Experiment  due  to 
disparities  in  the  two  terrain  data  bases. 

4.1.4.  Discussion.  All  designated  sites  should  have  been 
incorporated  into  the  connectivity  phase  to  test  systems  compatibility. 
Unexplained  system  crashes  caused  by  the  entry  of  other  member  sites  and 
their  respective  models  was  an  on-going  problem.  This  would  have  been 
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eliminated,  or  markedly  reduced,  with  more  complete  connectivity 
testing. 

4.2  Issue.  Technical  planning  and  coordination.  Despite  pre¬ 
conference  coordination  conferences,  details  governing  site  specific 
"technical*  requirements  were  not  adequately  formulated  nor  disseminated 
to  the  respective  facilities.  Examples  Include: 

4.2.1.  Discussion.  Agreed  versions  of  the  Terrain  Data 
Base  was  not  solidified  until  just  prior  to  the  week  of  presentation; 

4.2.2.  Discussion.  The  exercise  number  for  each  of  the 
demonstrations  was  not  Identified  early  on. 

4.2.3.  Discussion.  A  transcript  of  the  scenarios  time 
lines  were  not  provided  to  either  the  Military  command  group  or  site 
technicians  for  reference  and  critical  cueing. 

4.2.4.  Discussion.  Key  supporting  members  of  the  support¬ 
ing  contractor  community  need  to  be  Included  In  appropriate  pre¬ 
conferences  and  coordination  meetings.  Last  minute  changes  and/or 
attempts  to  comply  with  "late  breaking"  demonstration  requirements  were 
too  numerous  to  mention. 
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War  Breaker  Site  Integration  Test  Procedure 

DRAFT  W 
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INTRODUCTIOX 

The  use  of  these  procedures  is  a  start  at  identif^g  all  of  the  requirements  on  simulation  applications  in  c; 
be  involved  in  the  War  Breaker  DIS  escercise.  It  does  not  supersede  the  requirements  stated  in  War  Bre?  V* 
Working  Group  meetings,  etc.  This  is  provide^  as  a  reference  document ,  and  collection  point  foi 
present  and  future  connectiviQr  requirements  for  DIS  exercises.  Please  feel  free  to  provide  input  a  ic 
these  procedures.  ' 


USAGE  OF  THESE  TEST  PROCEDUKES: 

Note,  that  all  of  the  tests  in  this  document  will  not  apply  to  a  given  simulation  application  or  c::^. 
Some  tests  contained  in  this  document  will  not  be  enforced  for  the  Zen  Regard  Exercise. 


R  esults/Azmotations: 


P  indicates  the  System  Under  Test  (SUT)  successfully  passed/demonstrated 
a  requirement 


F  indicates  that  the  SUT  did  not  perform  a  test  step  adequately,  and  needs  to 


K*  with  the  War  Breaker  implementation  of 


make  a  chanse  in  order  to  comp! 
DIS 


TBD  indicates  that  a  SUT  still  n  teds  to  demonstrate  a  requirement 

N/A  indicates  that  a  SUT  does  not  need  to,  does  not  simulate  a 
requirement 


R  ic<»nme9adatiosis/Commeiiis: 

Please  submit  recommendations  and/or  comments  to  Steve  Hansen. 
Phone:  C703)  908-4420 
EMail:  shansen®wb.eom 


X 

REFERENCES:  War  Breaker  Interface  Requirements  Specification 

War  Breaker  Site  Entity  Sunulation  Li^ 


a.»sgt  OHi.  X 


I 


( 


1.0 . NCTWORK  LEVEL  CpNNECrivm*  \'ERlFICATION 

1.1  . Bt'directioiul  Communlcatiofl  Tests 

1.2  . Tfansmmaott  Test 

13 . Reception  Test 

2.0 . PDU  STRUCTURE  N'ERIFICATION 

2.1  . Entity  State  PDU  ContpUanee 

23 . Fife  PDU  Compliance 

23 . Detonation  PDU  CcmpUance 

2.4  . Emission  PDU  Compliance 

3.0 . 

3.1  . Position  and  Terrain  Elevation  Comparison  Test 

3.2  . Scenario  Entity  Transmission  ValidatioiL 

3.4  . Appearance/Visu^  RepresentatiM 

3.5  . Artieubtcd  Part  Validation 

3.6  . Entity  Time  Ovt 

3.7  . Static  Environment 

3.8  . Dead  Reekoninf  of  Statiorury  ^titles 

3.9  . Static  Load  Testins 

4.0 . DYNAi/flC  TESTS. 

4.1  . Dead  Reckoning  (DR)  Validation. 

4.2  . Packet  Rates 

43 . DR  Validation  of  Moving  Entities 

4.4  . Dynamic  Entity  Movement  and  Functional  Characteristics 

4.4. 1  . OutteriGrouno  Vehicles 

4.4.2  . Aiicfaft 

4.43 . Water  Craft 

4.4.4  . Munitions  and  Detonation 

4.4.5  . Destruction/Kll  of  an  Entity 

4.4.6  . Entity  Emissions 

5.0 . INTHUCTIVE  TESTS 

5.1  . Load  Testing 

5.2  . Information  T  ransport  Delays 

53 . Intercommunications 

53. 1  . Voice  Communications  , 

33.2  . .Tactical  Comunimications/Datakink 

5.4  . Data  CoUection/Analysia  •  SIMuLCER  Tests 

5.5  . Simulation  Management 

5.6  . Mission  Operations 

5.6. 1  . . Command  and  Control  Function  i 

Air  Operations  | 

Air  to  Air  Engueinents 

5.6.2.2  . Air  to  Ground  ugagcments 

5.6.3 . Ground  Operations 

5.63.1  . Surface  to  Surface  Engagements 

36.3.2  . Crround  to  Air  Engagements 
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ARPA  Itar  Breaker  {(703)  90Br«344] 


10/7/93  3I>«  PM 


Sjatfm  Vnd<r  Tts(  (SVIIDATA 

Date: 

Time: 

Site  Name: 

Site  IP  Address: 


1.0  NETWORK LE^’EL CONNECTIVITY  MESmCApON;  _ 

Network  level  tests  are  desisfled  to  deterxxufle  the  proper  compliaoee  with  Ethernet '  ersioi*  i.u,  -  -- 
DIS  protocol  header  information. 


1.1  Bi'directional  Conunuziication  T  esis 


Determine  if  bi-directional  communication  is  established  at  the  network  level  with  the  system  Under  : 
(SUT).  Use  a  PING  packet  originating  from  th^  War  Breaker  Facilitj*  (WBF)  to  determine  a  good  con 
If  PING  is  unavailable,  use  an  appropriate  alteijiative  test: 

SUT  Bi-directional  PING  test  successful. 


1.2  Transmission  T  est 


*  *?■' 


Determine  if  the  Under  Test  (SUT)  is  transmitting  Ethernet  packets  in  compliance  with  Erne:  n^;. 
UDPHP,  and  DIS.  Have  SUT  transmit  one  or  more  Entit)'  State  (ES)  Protocol  Data  Units  (PE  L 
have  the  SUT  locate  a  static  vehicle  at  the  fust  of  the  thirteen  test  points. 

SUT  is  transmitting  Ethernet  packets  in  compliance  with  Ethernet  Version  2.  UDP.I?. 
and  DIS. 


SUT  IP  address  is  assigned  and  used 


13  Reception  Test  ' 

Determine  that  the  SUT  can  receive  a  DIS  Entity  State  (ES)  packets.  Oeate  an  environment  at  the  WBF 
that  ES  PDUs  are  being  transmitted  to  the  SUTj 

SUT  is  receiving  DIS  packets  appropriately.  _ 


'  A^tPJW  V&r  Breaker  ((703  )  900^4344] 
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2.0  PDU  STRUCTURE  MERinCATION 

FDU  validity  tests  are  designed  to  test  the  proper  use  of  each  field  in  the  following  prioritized  DIS  PDUs; 
Entity  State  (£S),  Hre,  Detonation  (DETX  and  Emission. 


2.1  Entity  State  PDU  Compliance  I 

Through  the  use  of  PDU  inspection  tools,  indimte  PDU  dau  that  does  not  contain  appropriate  field  isfertr.  :  .< 
where  appropriate.  The  SUT  will  produce  valuM  for  the  below  PDUs  for  entities  that  the  SUT  can 
This  test  is  not  the  coordinate  conversion  nor  tl^  orientation  verification  test  This  test  is  primarily  used  :c 
identify  any  field  that  may  contain  unexpectedpad  data. 

SUT  Generates  and  fills  Entit)'  State  PDU  fields  correctly.  _ 


2.2  Fire  H)U  Compliance  Verify  that  the  SUT  can  produce  DIS  compliant  Fire  FC  \  " 
SUT  produce  a  Fire  PDU  through  whatever  means  necessary.  This  test  is  primarily  used  to  la 
that  may  contain  unexpected  bad  data. 

SUT  Generates  and  fills  Fire  PDU  fields  correctly. 


2.3  Detonation  PDU  Compliance  Veiif)' that  the  SUT  can  produce  DIS  compliant  Detonation  FI.  . 
Have  the  SUT  produce  a  Detonation  PDU  through  whatever  means  necessary.  This  test  is  primarily  used  to 
identify  any  field  that  mav  contain  unexpected  bad  data. 

I 

SUT  Generates  and  fills  Detonation  PDU  fields  correctly.  _ 


2.4  Emission  PDU  CompUancs  Verify  that  the  SUT  can  produce  DIS  compliant  Emission  P II 

Rave  the  SUT  produce  an  Emission  PDU  through  whatever  means  necessary.  This  test  is  primarily  ; 
identify  any  field  that  may  contain  unexpected  bad  data. 

SUT  Generates  and  Ells  Emission  PDU  Eelds  correctly 
(JMDIC ATE  errors  below  by  appropriate  element.) 


e.  :  C  l  n  H  X 


r* 


3.0  Static  Tests  SUT  will  senerate  traffic  on  the  Network,  and  the  WB  facili^’  wiH  vcniy  rec  -c  : 
correctness  of  the  data  in  the  appropriate  fields. 

3.1  Position  and  Terrain  £le^*ation  Comparison  Test  Will  check  coordinate  coq\  ert-ior.j : 
Genetic,  UTM,  SIMNETX.Y  to  DIS  coordinate  systems,  and  verify  the  SUT  is  able  to  place  and  see  o  :  , 
vehicles  according  to  DIS  standards. 

SUT  and  WB  will  place  Vehicle  at  the  Test  Point  Locations  depending  on  the  entity  type.  .A.11  ’.  eliick: 
have  0  velocity,  and  acceleration  and  be  facing  true  North. 

i 

Grfttaid  Elevation  Test  Sehm  Points! 

tJott:  rhe  tUvations  should  be  at  ground  level  at  these  locations. 


DIS.MChtt  shows _ SUN  conversion  QST  derived') 


Pil: 

Geoceatrie.X  » 
Geocentrie.Y  ■ 
Geocentric.Z  « 

3969171.703699 

3472838.383707 

3575301.^150 

Latitude  • 
Longitude  « 
Altitude  ■> 

34:18:46.08  or 
41:11:03.08  or 
252.981186  m 

34.312SG0 

41.1S43?? 

Pt2: 

Geoeentrie.X  » 
Geocentrie.Y  * 
Gcoccntfie,2  » 

3938804.480687 

3540809.783785 

3542403.009489 

Latitude  » 
Longitude  s 
Altitude  = 

33:57:14.77  or 
41:57:14.87  or 
318.993835  m 

33.954103 

41.954:3: 

Pi  3: 

Geocentrie.X  » 
Geocentrie.Y  = 
Gcocentric.Z  « 

4053555.280644 

3448552.042421 

3504271.802390 

Latitude  s 
Longitude  s 
Altitude  s 

33:32:23.41  or 
40:23:21.81  cr 
459.785461  m 

Pi  4: 

Geocentric.X  s 
Geocentrie.Y  « 
GeoeentrieJZ  = 

4074719.954666 

3410352347447 

3517243.024888 

Latitude  b 
Longitude  & 
Altitude  B 

33:40:45.98  cr 
39:55:39.99  cr 
594.130005  m 

35. 

Pt5: 

GeoeentrieJC  s 
Gcocentrie.Y  » 
Geoccntric.Z  = 

3976964.799880 

3511303.842253 

3529378.853102 

Latitude  » 
Longitude  b 
Altitude  B 

33:48:43.47  or 
41:26:29.83  or 
418.00000  m 

33.81207  i 

’  .<  ,1  -  ;  ■ 

^  • 

Pi  6; 

GeocentricJC  - 
Geocentrie.Y  = 
GeoccQtric.Z  = 

3908282.201657 

3563615.050453 

3552958.521979 

Latitude  » 
Longitude  = 
Altitude  B 

34:04:11.63  or 
42:21:32.06  or 
155.115128  m 

•i  *7  *  ■ 

Akcraft  T«t  Stftmi  |  ; 

SUT  ^l  place  aircraft  in  straight  and  level  flight  at  3000  ft  above  ground  level  (AGL)  starting  at  location 
specified  \sy  WB  facility,  with  a  heading  of  true  north,  at  its  cruise  speed.  WB  will  also  simulate  an  aircrif" 
sme  location,  speed,  heading.  The  two  entities  will  appear  at  the  same  altitude,  speed,  and  heading  as  : 
the  visual  reference  point  at  the  WB  facility. 


Water  Craft  Test  Sgt^; 

SOT  will  pUce  a  water  craft  at  a  location  determined  during  the  test  The  sea  state  shall  be  : 
with  a  heading  of  true  north,  at  its  cruise  speed.  WB  will  shall  abo  simulate  a  water  craift  at  a  iv.r. 
location  near  tliis  location,  with  the  same  heading,  attitude,  speed,  elevation. 
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SUT  poeition  is  located  \vithia  1  meter  of  test  point  position  as  reponed  on  WB  equipment. 
SUT  attitude  is  vtithin  0.00003623  radi  los  of  WB  entity’. 

WB  entity  is  located  witliin  1  meter  of  t  sst  point  position  as  reponed  on  SUT  equipment 
(Validation  rtguirtd  by/&  rtmott  site.) 

t 

WB  entipr  is  at  the  same  level.as  the  SUT.  '  . 

(Validation  rgquirtd  byiQ  remott  iiu.) 


3.2  Scenario  Entity  Trsoosmission  Validation.  TheSUT  shall$enerateandtra:^::^;:^  v  ' 
PDUs  for  each  entity*  that  it  shall  simulate  during  the  exercise  scenario.  (See  attached  IRS  S;:i  Z:. 
Simulation  List ) 

SUT  is  capable  of  acceptina  any  War  Breaker  or  other  remote  site  entities  that  u.*ill  be  si.mula:c 
the  scenario  as  detailed  below. 

(Use  WB  Entity  Generation  File  (to  be  created)  or  Logged  data  pom  previous  simulations  to  gsnerc 
neMork  traffic  of  each  possible  entity  from  any  site.) 

SUT  System  Performs:  With  No  System  degradation. 

With  Little  System  degradation. 

With  Some  System  degradation. 

With  Major  System  degradation. 


SUT  is  correctly  able  to  generate  all  entities  it  is  scripted  to  represent  for  the  test  sceaahc 
the  d^ription  below.  (Reference  IRS/Scenaxio  Details  for  list  of  entities  that  each  site  is  respoasi 
simulating). 

SUT  System  Performs:  "With  No  System  degradation. 

W^th  little  System  degradation. 

WTith  Some  System  degradation. 

W^th  Major  System  degradation. 


Indicate  Entities  SUT  is  sot  capable  of  simulating: 


r 


WB  facility  is  capable  to  accepting  eachi 


entity  the  SUT  can  generate. 


a  0  '  d 


esssT  riHx 


o' 


lU/7/yj  3U9  PM 


Pago  ‘. .  i 


3.3  ^  Static  Net>voi'k  Tra£Bc  SUT  shall  seed  Eatit}*  State  PDU  for  a  period  of  1  ; : .  i 

that  is  stationary,  or  is  in  steady  state  motion. 

Packet  rates  shall  be  received  from  SUT  at  a  rate  of  1  per  30  seconds. 


3.4  AppearanceAlsualKepreseziiation  These  tests  verify  the  SUT  can  correctly  -t.'f. ;; ; 
represent  entities  from  a  visual  standpoint. 

The  SUT  is  capable  of  correctly  displaying  each  entity  of  within  its  area  of  c^cern  and  imcrcs*  t  n 
scenario.  (V alidation  required  by/®  remote  site.) 


The  articulated  parts  are  represented  at 


3.5  Articulated  Part  V^alidation:  F^r  entities  with  articulated  parts,  those  parts  must  be  rcpresi  r.j ; 

in  the  WB  environment,  and  by  those  simulations  that  are  capable  of  displaving  articulated  parts. 


WB  WRM  correctly. 


WB  places  an  entity  with  articulated  parts  in  SUT  area  of  simulation. 


A^culated  parts  of  WB  entity  are  properly  represeated'displayed  on  SUT  visual  sceae 
(Validation  required  by/®  remote  site.) 


3.6  Entity  Time  Out 

WB  facility  shall  send  an  entity  to  the  SUT,  and  then  shall  not  update  the  Entity  PDU  for  73  seconds 
(IKS  Timc'Out  delay  is  72  seconds). 

SUT  shall  drop  the  entity  from  its  simulation  after  72  seconds. 


3.7  Static  Environment 

WB  facility  shall  set  Haze  and  Qoud  Layer(s) 


SUT  shall  recognize  Haze  setting 
SUT  shall  recognize  Qoud  Layer  settings 


This  capability  will  not  bs  simulated  in  Zen  Regard 


Dead  Beckoning  of  Stationary  Entities 

SUT  DR  algorithm  is  set  to  1,  (Don't  DR  me)  for  stationary  entities 


3.9  S^tic  Load  T  esting 

^  ftcility  will  j^encrate  network  traffic  representative  of  the  expected  amount  of  network  tr 
totes  for  static  entities  (ones  that  are  not  moving,  or  are  in  weady  state  motion).  7500  entities 
yuu  every  30  seconds,  plus  500  entities  transmitted  at  1  PDU  per  second. 


SUT  system  performance: 


Does  not  degrade 


T  g  :  s  T  n  H  J.  £  6.  —  -L 
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Upon  destniction,  the  entity  no  louser  produces  emissions  (SAM  site  destruction  for  e”  ^ 
SUT  entities  that  are  capable  of  reeeiving/monitoring  emissions  are  capable  of  doing  so. 
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4.4.3  Water  Ci’aft 

Simulated  water  craft  shall  be  bounded  by  water  •  not  travel  on  land. 

Water  e^t  shall  be  situated  is  the  water  similar  to  land  vehicles  on  land,  they  stay  in  water. 
If  water  craft  attitude  is  simulated,  it  will  respond  to  sea  state  appropriately. 


4.4.4  Munitions  and  Datonatioii  SUT  shall  fire  ordnance  that  detonsttes  hpon  impact  c; 

proximity. 

The  SUT  entity  is  able  to  fire  its  weapons. 

SUT  w'eapon  flyout  is  in  the  appropriate  direction. 

SUT  weapon  recognizes  collision  with 
the  weapon  occurs  appropriately. 

Appearance  of  fired  weapon  effects  is  a 
Upon  weapon  impact  with  target  eatit>-,  terrain,  etc. 

I 

Weapon  detonation  occurs  according  to  weapon  characteristics. 

WB  visual  scene  displays  flre/smoke  as  a  result  of  weapon  impact/detonation. 

4.4.5  Destruction/Km  of  an  Entity  WB  faciliQr  shall  to  shoot  to  destroy  a  SUT  entiry. 
Destruction  sequence  of  flames  and  snooke  is  observed  within  15  seconds. 

Appearance  of  target  entity  has  changed  to  Black  once  destroyed. 

Simulated  Entity  State  PDU  is  reduced  to  1  per  30  seconds  for  a  period  pf  10  minutes,  and  '.h  ::. 
longer  simulated. 


nother  entity,  or  the  ground,  and  detonation  &/or  terminstiot: 


ipropriate  (smoke  trail,  fire  etc.). 


4.4.6  Entity  Emissions  Sites  that  are  serimed  in  the  scenario  as  simulating  entities  with  radar  emisaions, 

and  or  receptions  must  be  capable  of  doing  so.  ]  « 


SUT  is  capable  of  simulation  of  emissiw  from  entities  identified  in  the  Scenario. 
Simulated  emissions  are  generated  at  the  appropriate  times. 


SUT  simulated  emission  generate  the  correct/appropriate  beam  azimuth,  elevation,  center, 
and  sweep. 


PDU  update  rates  for  emission  do  not  exceed  the  network  budget 


3s:sT  nHx 


Aye  tii0J  4i*4M  ^ 


1 


Aircraft: 

Altitude  elianges 
Attitude  ehanses 
Accelerations/Deeelentioii's 

gutter  VAicles: 

Heading  changes  due  to  turns 

Altitude  changes  as  a  result  of  terrain  elevation 

Speed/Stop/Start  changes  i 

SUT  entity  DR  update  is  issued  only  uijien:  ** 

>  0.9  meters  of  the  estimated  position  change  in  any  direction  occurs 
OR  Praition  change  of  >  5%  of  werali  bodj'  length  occurs 
OR  an  attitude  change  >  3  degnjes  occurs  ‘ 

OR  30  seconds  has  elapsed  since  last  update. 

Average  packet  rates  for  SUT  shall  not  be  greater  than  3  PDUs  per  second. 

SUT  entity  shall  not  jitter  in  the  W6  visual  sysum. 


4.4  Dynamic  Entity  Morement  and  Functional  Characteristics  These  tests  tvill 

functional  behavior  of  simulated  objects. 

4.4.1  Clutter/Ground  Vehicles 

SUT  Vehicles  follow  the  terrain  elevation  vtithout  going  above  or  below  the  terrain 
altitude. 

SUT  Vehicles  follow  roads  when  appropriate.  _ , 


SUT  Gutter  Vehicles  follow  each  other  in  a  coordinated  turn  (When  a  number  are  driving  down  a  rca< . 
they  don't  turn  all  at  once,  but  follow  each  other. 


SUT  Gutter  Vehicles  indicate  a  collision  when  hitting  another  object,  or  a  building  in  the  cln:'."  : 
environment 


4.4.2  Aircraft 

Simulated  aircraft  entities  shall  generate  a  collision  when  hitting  the  ground  at  excessive  velcc;:  ..- 


Aircraft  movement  shall  be  representative  of  actual  flight. 


T  X  •  d 
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Minor  lystem  degradation  oeeuxi. 
Some  s>'5tem  degradation  occurs. 
Major  system  degradation  occurs. 
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5.0  INliai  ACTHX  TESTS  These  tests  verify  that  the  SUT  interacts  appropriately  wita  ±z  r - 

simulation  sites  by  ^nerating  events  or  responding  properly  to  externally  generated  eves;  j. 

5.1  Load  Testing  ,  .  , 

SUT  is  able  to  simulate  the  number  of  entities  it  is  respo^ble  for  according  to  the  script  c: 
scenario  and  s>'stem  performance  (crash,  or  degrade  the  simulation  fidelity  of  the  entities  it  is  simulaii: 

<•* 

Does  not  degrade  .  *  . 

Minor  system  degradation  occurs. 

Some  system  degradation  occurs. 

Major  system  degradation  occurs. 

During  the  simulation  of  entities  that  thi  i  SUT  is  respoqsiMe  for,  voice  communications  pertorrr 

Does  not  degrade 

Minor  system  degradation  occurs. 

Some  system  de|radatio.n  occurs. 

Major  system  degradation  occurs. 


Then  SUT  is  able  to  receive  expected  number  of  simulated  entities  of  the  ZR  Scenario  (SCOO  jr.; 
and  system  performance: 

Does  not  degrade 

Minor  system  degradation  occurs. 

Some  system  degradation  occurs. 

Major  system  degradation  occurs. 

The  SUT  is  able  to  receive  at  least  KXWiPDUs  per  second  and  system  performance: 

'  1  Does  not  degrade  % 

Minor  system  degradation  occurs. 

Some  system  degradation  occurs. 

Major  system  degradation  occurs. 


SUT  ignores  network  traffic  with  invalid  exercise  ID's 


5.2  I^onnation  Transport  Dtlays  Simutation  information  being  passed  bet«.‘een  sites  must 
accomplished  without  excessive  delay’s. 

1 

Transjfort  delays  detailed  behw  mli  not  be  prior  to  Zen  Regard. 

DIS  netw’ork  to  Simulation  Application! 

Protocol  Translator  | 

Interface  Unit  ! 

Simulation  Application  to  DIS  Network 
ProtocM  Translator 
Interface  Unit 

Loop  back  "Ping"  Test 

Out  of  order  PDUs. 

Dropped  PDUs 

KG-95  Delay 

Network  Bridge  Delaj' 

5.3  Intercommtmicatioos  SUTs  mujit  be  capable  of  eommunicatini  with  other  remote  sites 
.  simulating  voice  radio  trafllc,  support  exercise  communication  with  the  War  Breaker  T est  Director,  is 

passing  tactical  data  if  the  SUT  is  scripted  to  perform  this  function  by  the  scenario. 

5.3.1  Voice  Communications 

SUT  is  able  to  receive  voice  communication  of  all  other  sites  scripted  in  the  Zen  Regard  See:;  - . 


SUT  is  able  to  send  voice  communications  to  all  other  sites  in  Zen  Regard  Scenario 
SUT  marks  its  voice  communication  PDUs  with  an  appropriate  Time  Stamp. 


No  overrun  of  voice  communications  is  heard  between  selected  frequencies  simulated  by  ’xt  :r. 

system. 

SUT  BLUE  Fbfees  are  not  able  to  hear  RED  voice  eommonications 

SUT  RED  Forces  are  not  able  to  hear  BLUE  voice  eonununieation 

White  Cell/Iest  Director  is  able  to  cominunieate  with  SUT  at  any  time  during  a  scenario. 


r 5.3.2  Tactical  Communications/Data  Link! 

I 

Tactical  Data  Networking  is  possible  between  applicable  sites. 

I 
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S.4  DaiaColUction/AadysU-SIMUUlEKTtsts 

Data  Logger  ta  able  to  receive  the  Net\\‘otk  Loading  without  sj’stem  performance  loss. 

(1000  roUs  per  second,  8000  Endtiea  being  simulated.  _ 

Data  Logger  is  able  to  capture  at  least  4  hours  of  simulation  play  at  a  time,  v^nthout  any  loss  of  PDU 
traffic.  i  r. 


Data  Logger  places  Time  Stamps  on  PDUs  received  (including  Voice  Comm) 

Data  Logger  is  capable  of  playing  backjrecorded  traffic 

Logger  Playback  is  capable  of  changing  Site/Application  IDs  of  recorded  traffic  so  that  SLT..'?; 
get  confused  about  receiving  "Themselves” 

Data  Logger  is  capable  of  recording  all  FDU  typ4s. 

Data  Logger  is  capable  of  filtering  out  PDUs  that  do  not  match  the  eurrent  Exercise  ID  :rf * 


If  On-line  playback  is  a  requirement  for  Dau  Anal^-sis,  the  Dau  Logger  most  be  capabis  s:  :  * 
playback  dau  being  sent  to  the  Network,  by  Site,  and  Field  of  View. 


The  Data  Logger  is  capable  of  logging  data  with  multi 
Digital  Voice  (Note;  Digiul  voice  set  to  ID  100  currently). 


multiple  Exercise  ID's  -  remote  network  traffic,  t- 


5,5  Simulation  Management  For  Zea  ijegard,  exercise  control  shall  be  conununicated  through  the 
intercommunication  system.  Simulation  Systexu  ^lall  need  the  capability  of  the  following  simulation 
management  functions,  udiich  will  be  communKated  to  them  over  the  intercom  system: 

SUT  has  the  correct  Exercise  ID  set  - 


SUT  is  able  to  Freeae  its  simulation  upon  command 

SUT  is  able  to  Start/Run  its  simulation  upon  command  x 

SUT  is  able  to  reset  to  a  TBD  point  in  the  exercise 


5.6  NCssion  Operations 

5.5.1  Command  and  Control  Functions  If  a  SUT  is  to  act  as  a  Command  and  Control  Suucr. 
Scenario,  then  it  must  be  capable  of  the  following: 

SUT  is  capable  of  eendtng  Tactical  Communications  to  simulated  entities  it  is  scripted  to  control 
(These  could  be  sent  via  data  linl^  fire  transfer, , intercom  etc.) 

e'SssT  nHX  —  J. 
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SUT  is  capable  of  reccivins  intelligence  data  from  sources  identified  in  the  scenario. 


5.6.2  Air  Openfions  Simolation  applications  that  support  air  operations  shall  demccstr:::^^ 
capability  according  to  what  they  are  scripted  to  perform  in  the  scenario. 


5.6.2.1  Air  to  Air  Engagements 

SUT  entities  capable  of  air<to>air  engagements.  ; 

h 

5.6.2.2  Air  to  Ground  Engagements 
SUT  is  capable  of  bombing  of  a  target. 

SUT  is  capable  of  air  to  surface  missile  engagements. 


5.6.3  Ground  Operations  Simulation  applications  that  support  ground  operations  shall  demonsc  a 
capability  according  to  what  they  are  scripted  to  perform  in  the  scenario. 


5.6.3.1  Surface  to  Surface  Engagemen  ts 

SUT  is  capable  of  surface  to  surface  tns  agements. 

5.6.3.2  Ground  to  Air  Engagements  ^ 


SUT  is  capable  of  ground  to  air  engagements. 
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WAR  BREAKER  SIMPLATION  TBST  PlUAN 


1.0.  Introduction 

The  purpose  of  this  document  is  to  define  the 
interoper2±>ility  requirements  of  the  WAR  BREAiCZR  Simulation 
network . 

1.1  Types  of  tests 


i)  Wide  A.rea  Network  connectivity 

ii)  Local  static  and  dynamic  tests 

iii)  Wide  Area  Static  tests 

iv)  Wide  Area  Dynamic  tests 

v)  Wide  Area  Interactive  tests 

vi)  Voice  communication  tests 

vii)  Phased  scenario  tests 

viii)  Full  scenario  test 


2 . 0  Testing 

2.1  Wide  Area  Network  Connectivity  Tests 

This  test  will  provide  the  basic  connectivity  testing  cf  each 
Wide  A.rea  Network  segment.  Testing  will  be  incremental  as 
equipment  is  installed  and  security  agreements  finalized.  It 
will  include: 

T1  testing  from  CSU/DSU  to  CSU/DSU  (loop-back  test) 

KG-S4  point-to-point  communication  (successful  keying  of 
two  KG-94s) 

Bridge/Router  to  Bridge/Router  communicaticn  (including 
WB  facility  diagnostic  capabilities) 

Bridge  to  Bridge  communication  delay  estimates 

2.2  Local  static  and  dynamic  tests 

This  test  will  be  conducted  by  all  sites  with  the  NFS  Stealth 
World  Reference  Model  capability.  This  will  provide  a 
capability  for  individual  sites  to  accomplish  static  and 
dynamic  testing  using  the  same  software  as  the  WAR  3P.Z.AKER 
facility  test  standard.  Testing  procedures  will  be  identical 
to  those  contained  in  Wide  -Area  Static  and  EVnamic  tests 
described  below - 

2.3  Wide  Area  Static  Tests 

Static  testing  will  be  accomplished  to  determine  DIS 
compliance  with  Entity  State  PDUs .  It  will  also  be  used  to 
determine  Database  correlation  between  a  particular 
simulation  and  the  database.  The  system  under  test  (SUT) 
will  be  required  to  locate  their  entity  at  selected  locations 


with  a  specific  oriencacion.  The  encity  will  be  viewed  on 
Che  ViB  Stealth.  Coordinates,  heading,  and  relative  location 
Co  significant  database  feacures  will  be  compared.  This 
procedure  will  be  repeated  at  a  number  of  locations  (What 
number  I  don't  know)  to  determine  database  correlation. 

Key  entities,  such  as  a  TEL,  F-15E,  Scud  missile,  and 
background  vehicles  (fuel  trucks,  etc.)  will  be  placed  at 
selected  locations  to  determine  the  capability  of  each 
simulation  to  correctly  process  incoming  DIS  entities. 

2.3.1  Network  Level  Tests 

2.3.2  Coordinated  Conversion  Coatparision  Tests 

Each  site  will  enter  the  following  locations  in  the  local 
coordinate  system  implemented  on  their  SUT: 


WGS-84:  TBD 
geocentric :  TED 
geodetic:  TBD 

WGS-a4:  TED 
geocentric :  TBD 
geodetic:  TED 

WGS~84:  TBD 
geocentric :  TBD 
geodetic :  TBD 

WGS-84:  TBD 
geocentric :  TBD 
geodetic:  TBD 

WGS-84:  TBD 
geocentric :  TBD 
geodetic :  TBD 


Coordinates  shall  be  provided  for  each  SUT  in  .iSCII  format . 
The  local  coordinates  will  be  rim  through  the  SUT's 
coordinate  conversion  routine  and  results  compared  with  the 
cooresponding  WGS-84  coordinates.  Coordinate  conversions  from 
local  coordinates  to  WGS-S4  shall  be  within  -r/-  1  cm. 

2.3.3  Appearance  Tests 

2. 3. 3.1  Location  Test 

2. 3. 3. 2  Attitude  Test 


2.4  Wide  Area  Dynamic  Testing 


wide  Area  Dynamic  tescing  will  furcher  case  a  simulacicr. ■  s 
encity  state  PDU.  Entities  will  be  raqnired  to  start  at 
designated  positions  and  move  (drive  or  fly)  on  each  of  the 
cardinal  headings .  Their  motion  will  be  observed  on  the 
stealth  to  verify  correct  behavior--speed,  orientation, 
smooth  motion,  appearance. 

In  addition,  simulations  with  the  capability  to  launch 
weapons  will  be  required  to  release  weapons.  Weapon  flyout 
will  be  observed  for  correct  behavior.  This  will  test  the 
fire  and  detonate  PDU. 

The  dynamic  testing  will  also  be  used  to  test  the  start, 
stop,  and  freeze  PDUs  (simulation  management)  .  Each 
simulation  will  be  required  to  react  properly  to  start,  stop, 
and  freeze  PDUs  issued  from  the  WB  facility. 

During  individual  site  dynamic  testing  with  the  WAP.  BREAKEP. 
facility,  network  loading  data  will  be  collected  for  each- 
simulator.  Also,  the  data  collection  tcols  at  the  ViAR 
BREAKER  facility  and  other  sites  will  be  tested.  Data  will 
be  analyzed  after  test  for  proper  operation  by  the  S.AIC  and 
completeness  as  a  system  engineering  to  tool  by  E.AH. 


^2  ^^S^Wide  Area  Interactive  Testing 

During  Wide  .Area  Interactive  testing,  one  site  will  network 
through  the  WAR  BRE-AKER  facility  all  other  sites.  The  site 
under  test  will  be  scheduled  to  test  with  other  W.AR  BPELAKEP. 
sites  individually.  Connectivity  will  be  established  (bridge 
to  bridge)  prior  to  scheduled  test  time,  and  simulation  test 
time  with  each  site  will  be  adhered  to.  Problems  encountered 
during  test  will  be  retested  during  a  subsequently  scheduled 
test  period. 

These  test  will  be  structured  to  focus  cn  the  interaction 
between  simulations  not  tested  during  previous  test. 
Simulations  transmitting  emissions  will  tested  by  those 
simulations  will  capable  of  detecting  those  emissions. 

Weapons  delivery  simulations  will  be  tested  with  their  target 
simulations . 

-Again  during  this  test,  data  collection  tools  operation  will 
be  verified  by  S-AIC  and  validated  by  5-AH. 


'  2^  Voice  Conmninication  Tests 

Limited  voice  testing  will  be  accomplished  during  all  phases 
of  testing.  The  transmit  and  signal  PDU  of  each  site  will  be 
tested.  Channel  selection,  frequency,  voice  quality  will  be 
tested.  Each  operational  (by  scenario)  channel  will  tested 


individually  for  ccmmunicaciou .  Coinmuriicacicris  cnen  wij.1  ce 
tssoad  to  ensure  no  bleed  tbrouch  and  no  cornmunr  cat  ions  can 
be  received  by  simulations  restricted  from  tncse  cnannels . 

2.7  Pliased  Scenario  Tests 

Phased  Scenario  testing  will  test  those  sites  involvec  in 
each  discrete  phase  of  the  Scud  hunt  scenario.  All  sites 
involved  in  the  Wide  Area  Search  phase  will  be  tested.  Then 
the  Focused  Search,  Strike,  and  BDA  phases  will  be  tested. 

2.8  Full  Scenario  Test 

Full  Scenario  Testing  will  differ  fromPhasea  Scenario 
Testing  in  that  all  sites  will  be  on  line  and  in^their  .ATO 
positions  waiting  for  the  mission  to  transition  rrom  one 
phase  to  the  other.  Each  simulation  will  react  to  previous 
phase  realtime  results. 


AdMnoad  OMfiNilad  Simuiition 


APPENDIX  D  COMMUNICATIONS  PLAN 


October  15,  1993 


Zen  Regard  Communications  Plan  (By  Circuit) 


# 

Circuu 

Frequency 

DIS  Voice 

Preset  Entities/Sites 

D 

"Psuedo" 

Data  Link 

N/A 

N/A 

EXCAP,  Warrior  (TEC),  Constant 
Source  (TACCSF),  GIST  (WBF),  ATP 
(NRaD) 

J 

JTIDS/ 

TADILJ 

N/A 

N/A 

CRC  (TACCSF),  AOC-Receivc 

Only  (TACCSF),  AW  ACS  (TACCSF), 
Patriot  Bde  and  ICC  (TACCSF) 

P 

PADEL 

N/A 

N/A 

Patriot  Bde  and  ICC  (TACCSF),  Patriot 
Fire  Unit  (TACCSF) 

VI 

Aircraft 

Control 

238037120 

1 

All  AF  A/C  (TACCSF,  MDA,  WL), 
WBF  (EXCAP  A/C\  AW  ACS 
(TACCSF),  JSTARS  (TACCSF), 
COBRA  BALL  (TACCSF),  F-18  (Pax 
Riyer),  F-14  (NRaD) 

V2 

Army  Air 
Surveillance 

238137120 

2 

GUARDRAIL  (WBF/EXCAP), 

DOCC  (TEC)  * 

V3 

Air 

Operations 

238237120 

3 

AOC  (TACCSF),  AWACS(TACCSF) 

V4 

Air 

Coordination 

N/A 

N/A 

AOC  (TACCSF),  CRC  (TACCSF) 

V5 

Patriot 

238337120 

4 

CRC  (TACCSF),  Patriot  Control 

Battery  (WBF) 

V6 

Army 

Coordination 

238437120 

5 

AOC/BCE  (TACCSF),  DOCC 
(TEC) 

V7 

Navy 

Coordination 

238537120 

6 

AOC/NCE  (TACCSF),  MARS 
(Dahlgren),  RESA  Remote 
(Dahlgren),  RESA  (NRaD), 

SCILitAPL),  OBT-UAV  (WBF) 

V8 

Army  Command 

238637120 

7 

DOCC  (TEC),  AVTOC  (Ft  Rucker), 
AH-64AS  (Ft  Rucker),  MLRS  Fire  Unit 
(TEC),  Mech  Team  (Ft  Knox) 

V9 

Army  JSTARS 

239037120 

N/A 

JSTARS/GSM  (TEC),  DOCC  (TEC) 

vio 

UAV  Control 

238737120 

8 

AOC  (TACCSF),  HALE-UAV/GCS 
(WBF),  MUSTRS  (WBF) 

Vll 

AF  JSTARS 

238837120 

9 

JSTARS  (TACCSF),  AOC  (TACCSF) 
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u 

H 

Circuit  Name 

Frequency 

DIS  Voice 
Preset 

Entities/Sites 

V12 

Control  and 
Reporting 

N/A 

N/A 

AWACS  (TACCSF),  CRC  (TACCSF) 

V13 

Exercise 

Control 

238937120 

10 

WBF,  TACCSF,  TEC,  NRaD,  WL, 
MDA,  NTF,  Dahlgren,  Ft  Rucker,  Ft 
Knox,  APL,  Pax  River 

Default 

438037120 

None 

All  Comm  Circuits 
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Zen  Regard  Communications  Plan  (By  Site) 

Si{£  Circuits 

War  Breaker  D  ("Psuedo"  Data  Link),  V 1  (Air  Control),  V2  (Army  Air  Surveillance),  V5 
(Patriot  Control),  V7  (Navy  Control),  VIO  (UAV  Control),  V13  (Exercise 
Control),  Also  need  to  monitor  all  circuits  for  data  collection  purposes. 
Total  =  0  Internal  Circuits  and  13  External  Circuits. 

TACCSF  D  ("Psuedo"  Data  Link),  J  (JTIDS/TADIL  J),  P  (PADBL),  V 1  (Air  Control), 

V3  (Air  Operations),  V4  (Air  Coordination),  V5  (Patriot  Control),  V6 
(Army  Coordination),  V7  (Navy  Coordination),  VIO  (UAV  Control),  VI 1 
(AF  JSTARS),  V12  (Control  and  Reporting),  V13  (Exercise  Control).  Total 
=  4  Internal  Circuits  and  6  External  Circuits. 

MDA  VI  (Air  Control),  V13  (Exercise  Control).  Total  =  2  External  Circuits. 

Wright  Labs  VI  (Air  Control),  V13  (Exercise  Control).  Total  =  2  External  Circuits. 

TEC  D  ("Psuedo"  Data  Link),  V2  (Army  Air  Surveillance),  V6  (Army 

Coordination),  V8  (Army  Command),  V9  (Army  JSTARS),  V13  (Exercise 
Control).  Totd  =  1  Internal  Circuit  and  4  External  Circuits. 

NRaD  VI  (Air  Control),  V7  (Navy  Coordination),  V13  (Exercise  Control).  Total  = 

3  External  Circuits. 

NSWC  Dahlgren  VI  (Air  Control),  V7  (Navy  Coordination),  V13  (Exercise  Control).  Total  = 
3  External  Circuits. 

NTF  V13  (Exercise  Control).  Total  =  1  External  Circuits. 

Ft  Rucker  V8  (Army  Command),  V13  (Exercise  Control).  Total  =  2  External  Circuits. 

Ft  Knox  V8  (Army  Command),  V13  (Exercise  Control).  Total  =  2  External  Circuits. 

APL  V7  (Navy  Control),  V13  (Exercise  Control).  Total  =  2  External  Circuits. 

Pax  River  VI  (Air  Control),  V7  (Navy  Control),  V13  (Exercise  Control).  Total  =  3 

External  Circuits. 
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Zen  Regard  Communications  Plan  -  War  Breaker  Facility 

Operations  Table: 

-  Seat  1  through  5  on  analog  voice  circuit  channel  1. 

-  Seat  3  with  DIS  Voice  keypad,  with  transmit  set  on  preset  10  (Exercise  Control),  receive 
set  to  presets  1  through  10. 

-  Portable  headset  set  to  analog  voice  circuit  channel  1 . 

Front  Table: 

-  Seat  1  and  2  on  analog  voice  circuit  channel  1 . 

Engineering  Pod: 

-  Aristotle:  Receive  and  transmit  set  to  preset  10  (Exercise  Control). 

-  Bernoulli:  Receive  and  transmit  set  to  preset  10  (Exercise  Control). 

-  Coulomb: 

-  LADS  SAF:  Receive  and  transmit  set  to  preset  10  (Exercise  Control). 

-  MARS:  Receive  set  to  preset  10  (Exercise  Control)  and  preset  8  (UAV 
Control),  transmit  set  to  preset  8  (UAV  Control). 

'  Portable  headset  set  to  analog  voice  circuit  channel  1 . 

SimCore  Pod; 

'  Descartes:  Receive  and  transmit  set  to  preset  10  (Exercise  Control). 

-  Euclid:  Receive  set  to  preset  10  (Exercise  Control)  and  preset  8  (UAV  Control), 
transmit  set  to  preset  8  (UAV  Control). 

-  Faraday:  Receive  set  to  preset  10  (Exercise  Control)  and  preset  6  (Nav\'  Control), 
transmit  set  to  preset  6  (Navy  Control). 

-  Galileo:  Receive  and  transmit  set  to  preset  10  (Exercise  Control). 

-  Portable  headset  set  to  analog  voice  circuit  channel  1. 

Background  Sound  System; 

*  Set  to  receive  preset  1  (Air  Control). 
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